home *** CD-ROM | disk | FTP | other *** search
/ Programming Languages Suite / ProgramD2.iso / Database Designers / Rational Rose 2000 / Rational Setup.EXE / common / OutOfTheBox / synchronizer rules / synchronizer_rule_template.rsd < prev    next >
Encoding:
Text File  |  1999-09-01  |  8.2 KB  |  183 lines
  1. # File:        synchronizer_rule_template.rsd
  2. #
  3. # Purpose:    This file contains a template for Rational synchronizer rules. You can
  4. #        copy this file, or cut and paste the contents into your own rules file.
  5. #        
  6. #        For each of the clauses there is a description of the syntax, the
  7. #        semantics, and the possible values that can be used for the variable
  8. #        data.
  9. #
  10. # Usage:    Read the file for comments about how to write your rule. Look for the
  11. #        fields enclosed by angle brackets <like this>. Decide if the clause
  12. #        applies to your rule. If it does, replace the text in angle brackets,
  13. #        including the brackets, with the appropriate value. If a clause does
  14. #        not apply to your rule, remove the complete clause.
  15. #
  16. #        You may choose to remove the comments from this file after you have
  17. #        written your rule. This will make your final rules more readable.
  18. ######################################################################################
  19. # Every rule in your rule file must start with a begin clause. If you give your rule
  20. # a meaningful name it will be easier to remember what it does. If you use spaces in
  21. # the name you must enclose it in quotes.
  22.  
  23. begin rule <rule name>
  24.  
  25. ######################################################################################
  26. # You can provide a description of your rule. This is optional but highly recommended.
  27. # The description will appear in the synchronizer session window when you display
  28. # information about the rule. The description may be any length. But try to keep
  29. # it short for easy viewing. Briefly describe the purpose of the rule and the data
  30. # transfer that it causes.
  31.  
  32. description 
  33. {
  34. <Your rule's description. This can go across multiple lines.>
  35. }
  36.  
  37. ######################################################################################
  38. # You must identify the projects to which this rule applies. Every rule has a source
  39. # project and a target project. These tell the synchronizer where the source and target
  40. # items live. The projects are projects from one of the supported domains, modeling
  41. # (Rational Rose), requirements (Rational RequisitePro), or test (Rational TestStudio).
  42. # For any rule, the source and target project may be the same. If there are any spaces
  43. # in a project's name, you must enclose it in quotes.
  44.  
  45. projects <source project name> to <target project name>
  46.  
  47. ######################################################################################
  48. # You must specify the item types from the source and target projects for which this
  49. # rule applies.  Different project types contain different item types. If the item
  50. # type name contains spaces it must be enclosed in quotes.
  51. #
  52. # Item types are case sensitive and must be spelled exactly as shown in the following
  53. # table or in the domain project.
  54. #
  55. # The following identifies the possible item types that are supported for the different
  56. # project types:
  57. #
  58. #    If the project type is...    You can use these item types...
  59. #    -------------------------    -------------------------------
  60. #    Rose                "Use Case"
  61. #                    Actor
  62. #                    Package
  63. #                    "Sequence Diagram"
  64. #                    Class
  65. #
  66. #    TestStudio            Script
  67. #
  68. #    RequisitePro            Any requirement type. You must type the
  69. #                    name of the requirement, not the tag, exactly
  70. #                    as it shown in the Requirement Tab of the project
  71. #                    properties display in RequisitePro.
  72.  
  73. items <source item type> to <target item type>
  74.  
  75. ######################################################################################
  76. # You now supply one or more data transfers. Each transfer is described by a pair or
  77. # properties, or attributes, one in the source and one in the target item. The data
  78. # transfer may go from either the source to the target or from the target to the source.
  79. # In fact, there may be data transfers in both directions specified in a single rule.
  80. # For each transfer, the first property specified is the source of the data (the
  81. # item is called the broadcaster for this transfer). The second property specified is
  82. # the destination of the data (the item is called the receiver for this transfer).
  83. # The data transfers are introduced by the keyword "properties". There is only one
  84. # "properties" clause per rule. There may be as many data transfers as you wish
  85. # following this keyword.
  86. #
  87. # Note the attributes are case sensitive and must be written exactly as defined in the
  88. # following table, or in the domain project.
  89. #
  90. # There are different properties for different item types. The following table
  91. # identifies the possibilities:
  92. #
  93. #    If the item type is...        You can use these properties (attributes)...
  94. #    --------------------------    ---------------------------------------------
  95. #    Rose "Use Case"            Name
  96. #                    Documentation
  97. #                    Stereotype
  98. #                    Rank
  99. #
  100. #    Rose Actor            Name
  101. #                    Documentation
  102. #                    Stereotype
  103. #
  104. #    Rose Package            Name
  105. #                    Documentation
  106. #                    Stereotype
  107. #                    Global
  108. #
  109. #    Rose Class            Name
  110. #                    Documentation
  111. #                    Stereotype
  112. #                    "Export Control"
  113. #                    Cardinality
  114. #                    Space
  115. #                    Persistence
  116. #                    Concurrency
  117. #                    Abstract
  118. #
  119. #    Rose Sequence Diagram        Name
  120. #                    Documentation
  121. #
  122. #    TestStudio Script        Name
  123. #                    "Description" (must be in quotes)
  124. #                    Requirement (used only for associating
  125. #                        requirements. See Note 1 below.)
  126. #
  127. #    RequisitePro requirement    Any attribute for the requirement type. Enclose
  128. #                    in quotes if there are any spaces. All 
  129. #                    requirements have the following attributes:
  130. #                    Text, Tag, Key (See Note 2 below.)
  131. #
  132. # Properties are defined by the format: source.<property> or target.<property> where
  133. # "source" and "target" identify the source or target item as defined in the "items"
  134. # clause. If you have to put quotes around a property, e.g. "Planned Iteration" you 
  135. # would do it like this: target."Planned Iteration".
  136. #
  137. # Note 1: You would use the Requirement property of a TestStudio script when you
  138. #    want to associate the script with a requirement. In order to do this you
  139. #    use the special property "object" as in the following example, where the
  140. #    source is assumed to be a requirement and target the script. You can only
  141. #    use "init" with this property.
  142. #
  143. #        source.object init target.Requirement
  144. #
  145. # Note 2: For these  attributes, Tag and Key are read only and cannot be set by a 
  146. #    synchronizer rule. The Text attribute may be set as well as read only if the
  147. #    requirement is not a document-based requirement.
  148. #
  149. # In the following line, we use "to" between the two properties. This means that
  150. # on the first application of the rule, the receiving field, if it is in the target item,
  151. # will be created and initialized with the source data. On subsequent synchronizations
  152. # the data will be re-transferred if the values are different. If you only wish to cause
  153. # the data transfer to occur one time, when the target item is initially created, use
  154. # the keyword "init" or "initialize" instead of "to".
  155.  
  156. properties
  157.     <source/target>.<property> to <source/target>.<property>
  158. #    add as many more transfers as you need for this rule
  159.  
  160.  
  161. ######################################################################################
  162. # You may have an optional clause which can constrain the application of the current
  163. # rule. This is done by performing an equality test to a single property in the
  164. # source item. If the test results in a match, then the rule will be applied to the
  165. # source and target items. If the test results in a false result, the rule will not be
  166. # applied to the source and target item pair.
  167. #
  168. # If you want this rule to always apply, remove the following clause.
  169.  
  170. applies when <source property> = <value, use quotes if there are any spaces>
  171.  
  172. ######################################################################################
  173. # You may create a traceability link from the source to the target or the target to
  174. # the source if this is allowed in the appropriate domains. Currently this is only
  175. # possible if both the source and target items are in the requirements domain. If this
  176. # is the case you may place one of the following two statements in your file:
  177. #
  178. #        trace source to target
  179. #        trace target to source
  180.  
  181. ######################################################################################
  182. # Every rule must end with an end clause.
  183. end rule